Amazon EKSベストプラクティスガイドにクラスターアップグレードの章が追加されました
EKS Best Practices GuidesにBest Practices for Cluster Upgradesが追加されました。
EKSクラスターのアップグレードは悩みのタネだと思います。こちらのドキュメントを待ち望んでいた方も多いのではないでしょうか。
この記事では、ポイントとなりそうな部分を抽出して紹介したいと思います。
アップグレード方針
常に最新の状態に保つことを推奨されています。
Kubernetesコミニティは一定の時点(通常は1年)をすぎると、CVEパッチのリリースを停止します。
古いバージョンのCVE提出も推奨していないこともあり、脆弱性の報告もされないことがあります。 そのため、古いバージョンで脆弱性が発生した際に、通知も修復もされないままになります。
EKSはサポート終了日までにクラスターがアップグレードされなかった場合、サポートされる次のバージョンに自動的にアップグレードされます。
バージョンにより廃止や非推奨になるAPIがあります。事前にテストせずにアップグレードするとワークロードに影響が出る可能性があります。
そのため、自動アップグレードに任せるのではなく、主体的に最新の状態に保つことが推奨されています。
EKSのリリースサイクル
EKSバージョンは以下のリリースサイクルになっています。
- 毎年3つマイナーバージョンがリリースされる
- 各マイナーバージョンは約14ヶ月間サポートされる
最低でも14ヶ月に1回はアップグレードの必要があります。
しかし、一度に複数のバージョンをアップグレードすると変更範囲が大きくなります。
最新の状態を保つことで、一回あたりのアップグレード作業の影響範囲が小さくなります。
Amazon EKS Kubernetes のバージョン - Amazon EKS
アップグレード戦略
アップグレード戦略は以下があります。
- インプレースアップグレード: 既存のEKSクラスターに対してアップグレードを行う
- Blue/Greenアップグレード: 新バージョンでEKSクラスターを用意して、動作確認後旧EKSクラスターから切り替えを行う
| 項目 | インプレースアップグレード | Blue/Greenアップグレード |
|---|---|---|
| 対応工数※1 | ◯ | △ |
| 複数のEKSバージョンを一度に変更 | ✕ | ◯ |
| コスト | ◯ | △ |
| 古いバージョンへの切り戻し | ✕ | ◯ |
※1 ワークロードの再デプロイやDNS等の切り替え等、必要な作業の対応工数
Blue/Greenのほうが、できることや安全性は高いです。 一方、EKSクラスターを新規に作成する分、アップグレードにかかる費用や作業量は多くなります。
運用している環境にあった方法を選択する必要があります。
アップグレードの流れ
アップグレードは以下の流れで、実行します。
- KubernetesとEKSのリリースノードを確認
- クラスターのバックアップを作成(オプション)
- アドオンの互換性を確認(必要に応じて、アップグレード)
- ワークロード内の非推奨または削除されたAPIの使用状況を特定・修正
- コントロールプレーンをアップグレード
- kubectlを更新
- データプレーンをアップグレード
詳細は本家のドキュメントを確認いただくとして、いくつかピックアップして紹介します。
1. KubernetesとEKSのリリースノードを確認
公式のユーザーガイドにてリリースノートを確認します。 リリースノートには、各バージョンの変更点や考慮事項が記載されています。
Amazon EKS Kubernetes のバージョン - Amazon EKS
この際に、次のバージョンだけではなく更に先のバージョンに大きな変更点が無いかを確認しておくとよいです。
例えば、1.24でCRIのサポートが終了されました。
こういった大きな変更には、通常のアップグレードより対応に時間がかかることがあります。
必要に応じて、KubernetesのCHANGELOGも確認しておきましょう。
4. ワークロード内の非推奨または削除されたAPIの使用状況を特定・修正
EKSコントロールプレーンをアップグレードする前に、削除されたAPIの使用状況を特定する必要があります。
手動で確認することもできますが、以下のようなツールを使うと便利です。
上記のツールは、以下のスキャン方法に対応しています。
- クラスターに対するスキャン
- マニフェストファイルに対するスキャン
マニフェストファイルに対してチェックを実行するほうが、誤検知が少なく正確です。
上記のチェックをCIに組み込むことが、おすすめされていました。
ちなみに、kube-no-troubleは以前は「クラスターに対するスキャン」のみでしたが、現在は「マニフェストファイルに対するスキャン」も可能です。
7.データプレーンをアップグレード
データプレーンのアップグレード中にワークロードの可用性を確保するために、以下の設定が役立ちます。
PodDisruptionBudgetsはノードを自発的な中断(ドレイン等)するときにKubernetes クラスター内に起動しておく「最低限必要なPod数」を設定できます。
topologySpreadConstraintsは、特定のトポロジードメイン（ノード、ゾーン、リージョンなど）間でPodの分散を制御を行えます。
組み合わせることで、最小限必要なPod数を保ちゾーンとノードにPodを分散することができます。
上記を設定したマニフェストのサンプルは以下をご確認ください。
AWS Resilience Hub はEKSをサポートしています。
Amazon EKS クラスターのインフラストラクチャを分析することにより、Amazon EKS クラスターの耐障害性を評価することが可能です。
KubernetesのDeployment,Pod等も調べて評価や推奨事項を提示してくれます。
おわりに
Amazon EKSベストプラクティスガイド (クラスターアップグレード編)の紹介でした。
アップグレードの方針や流れから、アップグレード時に便利なツールまで説明してくれています。
アップグレードの方針を決める際は、目を通してみることをおすすめします。
以上、AWS事業本部の佐藤(@chari7311)でした。
![[レポート]Amazon EKS for edge and hybrid use cases #KUB310 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
